MBMS is a Point-To-Multipoint (PTM) content delivery service specified by the 3rd Generation Partnership Project (3GPP). MBMS enables an efficient delivery of content to multiple recipients in a cellular communications network. The content may be delivered in the form of content streams (e.g., mobile TV or radio programs) or content files (e.g., news updates).
Aspects of MBMS and evolved MBMS (eMBMS) are defined in 3GPP Technical Specification (TS) 26.346. Further information regarding MBMS, and in particular regarding the MBMS architecture in connection with cellular communications networks, is presented in F. Hartung et al., “Delivery of Broadcast Services in 3G Networks”, IEEE Transactions on Broadcasting, Vol. 53, No. 1, March 2007, p. 188 to 199. As discussed therein, the central component of the MBMS architecture is a so-called Broadcast Multicast Service Center (BM-SC).
MBMS is functionally split into an MBMS Bearer Service and an MBMS User Service. FIG. 1 schematically illustrates the relationship between the MBMS Bearer Service and the MBMS User Service.
The MBMS Bearer Service shown in the lower half of FIG. 1 generally addresses MBMS transmission procedures below an Internet Protocol (IP) layer based on multicast or broadcast bearers. An individual MBMS Bearer Service is identified by a Temporary Mobile Group Identity (TMGI). A single, globally unique TMGI is allocated per MBMS Bearer Service by the BM-SC. Content delivery via the MBMS Bearer Service may involve PTM or Point-To-Point (PTP) transmissions.
The MBMS User Service shown in the upper half of FIG. 1 generally addresses application or service layer protocols and procedures based on, for example, the Real Time Protocol (RTP) for streaming services and the FLUTE protocol (see Internet Engineering Task Force, IETF, RFC 3926) for file delivery services. A FLUTE content delivery session is defined in a Session Description Protocol (SDP) file, which contains parameters that allow a mobile client to receive a mobile file delivery. Such parameters typically include an IP Multicast address, a User Datagram Protocol (UDP) port and the TMGI.
At present, there is no detailed timing and/or location information part of the FLUTE delivery session concept. As an example, there is no guarantee that a mobile client, also called User Equipment (UE) in 3GPP TS 26.346, is in an MBMS Service Area when an MBMS bearer is started. Further, an MBMS receiver shall continuously monitor the MBMS notification channel (i.e., the MBMS Control Channel, MCCH) and wait for an upcoming file delivery session, which is indicated by a TMGI on the MCCH. Continuously monitoring the MCCH is battery draining for a mobile client and will thus reduce its operating time.
TDocs S4-110448 (TSG-SA#64 meeting, 11 to 15 Apr. 2011, San Diego, Calif., USA) and S4-110621 (TSG-SA#65 meeting, 15 to 19 Aug. 2011, Kista, Sweden) discuss the issue of power efficient monitoring of MBMS transmissions. As confirmed therein, continuous monitoring of MCCHs for active MBMS bearers of interest and the associated unnecessary reception of MBMS data increases the power consumption of mobile clients. In this regard, TDoc S4-110621 suggests adding schedule information so that the mobile clients can deactivate MCCH monitoring when MBMS bearers of interest are certainly not active. Specifically, it is suggested that the FLUTE File Delivery Table (FDT) should describe the time window (by two parameters called startTime and endTime) when each file is scheduled to be broadcasted.
It has been found that transmitting schedule information in the FLUTE FDT suffers from several drawbacks. For example, the timing in the FDT is only applicable to files within the FLUTE session (this can be referred to as online for in-band information). In consequence, the timing of content (e.g., as identified by the service class) which is across different FLUTE flows cannot be properly described.